Wprowadzenie do systemu

Zarządzanie procesami pracy

Metody i techniki modelowania, wdrażania i eksploatacji systemów informatycznych realizowanych w oparciu o architekturę procesową uzyskały po wielu latach status dojrzałej i w pełni akceptowanej dziedziny informatyki. Silnym wsparciem rozwoju techniki zarządzania procesami, a szczególnie narzędzi i metodyki modelowania procesów biznesowych, są prace organizacji Object Management Group (OMG) i opublikowany standard notacji graficznej BPMS 2.02.

Platforma docuRob®WorkFlow jest implementacji specyfikacji BPMN 2.02 rozbudowanej o takie możliwości jak zarządzanie ontologią procesów oparte o standard TopicMaps (ISO/IEC 13250) oraz własny język Business Process Query Language (BPQL).

Platforma oprogramowania narzędziowego docuRob® zawiera dodatkowo zintegrowane produkty docuRob®objectManager, docuRob®eForms oraz docuRob®ontologyManager. Oprogramowanie narzędziowe docuRob® zintegrowane ze środowiskiem webowym Angular i językiem programowania Java, wsparte dojrzała metodyką projektowania procesów biznesowych, stanowi silne podstawy dla realizacji dużych systemów informatycznych opartych o architekturę procesową.

Obszarem zastosowań naszego oprogramowania są organizacji biznesowe, jednostki administracyjne oraz instytucje badawcze. Podstawowe obszary zastosowań rozwiązań informatycznych wykorzystujących nasze oprogramowanie narzędziowe to:

• Automatyzacja procesów biznesowych i pracy grupowej
• Zarządzanie procesami badawczymi
• Zarządzanie obiegiem dokumentów
• Integracja rozproszonych systemów informatycznych
• Automatyzacja zarządzanie projektami

Przepływ sterowania

Podstawowym elementem zarządzania procesami pracy jest zdefiniowanie przepływu sterowania. docuRob®WorkFlow dostarcza ośmiu podstawowych konstrukcji do definicji przepływu sterowania:

• Punkt startowy – rozpoczyna proces, najczęściej jest związany ze zdarzeniem,
• Punkt końcowy – kończy proces albo jedną z jego ścieżek.
• Przejście z warunkiem – ustala kolejność między czynnościami. O ile jest zdefiniowany warunek, to przejście jest wykonywane jedynie wtedy, gdy warunek jest spełniony,
• Sekwencja – czynności w sekwencji są wykonywane po kolei ( zakończenie poprzedniej czynności powoduje rozpoczęcie wykonywania następnej czynności),
• Zrównoleglenie – czynności należące do dwóch równoległych ścieżek w procesie są wykonywane równolegle. Z tą konstrukcją wiążą się dwa operatory przepływu sterowania: rozdzielenie (AND-SPLIT) i złączenie (AND-JOIN),
• Alternatywa – tylko czynności należące do jednej z alternatywnych ścieżek zostaną wykonane. Z każdą ze ścieżek jest związany warunek wykonania tej ścieżki i maksymalnie tylko jeden z nich może być spełniony. Z tą konstrukcją wiążą się dwa operatory przepływu sterowania: rozdzielenie (XOR-SPLIT) i złączenie (XOR-JOIN),
• Zdarzenie - (ang. "event") to akcja lub sytuacja, która jest wykrywana przez oprogramowanie i może wymagać reakcji systemu. Przykłady zdarzeń to kliknięcia myszką, naciśnięcia klawiszy, sygnały przychodzące z urządzeń peryferyjnych, zmiany w stanie systemu czy komunikaty od innych programów.
• Opcja – czynności są wykonywane w zależności od spełnienia warunku poszczególnych ścieżek. Możliwe jest, aby więcej niż jeden warunek był spełniony. Z tą konstrukcją wiążą się dwa operatory przepływu sterowania: rozdzielenie (OR-SPLIT) i złączenie (OR-JOIN),
• Podproces – czynność może być innym procesem (podprocesem).

Przepływ danych

Kolejnym ważnym aspektem definicji procesu jest określenie przepływu danych. docuRob®WorkFlow dostarcza elastycznych mechanizmów do definiowania następujących obiektów danych pomiędzy przekazywanych pomiędzy elementami modelu powiązanych procesów:

• Parametry (wejściowe/wyjściowe) procesu – proces może być widziany jako tzw. czarna skrzynka. W tym przypadku proces otrzymuje pewne dane wejściowe, wykonuje się i zwraca rezultaty tego wykonania.
• Atrybuty/zmienne procesu – aby zapamiętać dane przetwarzane w ramach procesu system dostarcza możliwość definiowania atrybutów procesu. Atrybut może być typu prostego (tekst, liczba, wartość logiczna, data, itp.) oraz typu złożonego (dokument XML). Dany atrybut może być przechowywany bezpośrednio w repozytorium procesów lub poza platformą zarządzania procesami, w zewnętrznym systemie. W tym drugim przypadku w kontenerze procesu jest utrzymywane jedynie wskazanie na dany atrybut a w momencie konieczności jego odczytu jest wykonywane wywołanie właściwej usługi (także zapytania SQL) zwracającej odpowiednią wartość.
• Atrybut może być wielowartościowy. W takim przypadku, każda z wartości zapisywana jest pod innym kluczem. Atrybuty są zgrupowane w ramach kontenera procesu.
• Parametry aplikacji wywoływanych w ramach czynności – tak jak dla procesu każda z czynności może mieć parametry wejściowe i wyjściowe. Parametry te są przekazywane do aplikacji wywoływanej na rzecz danej czynności.
• Reguły mapowania – w celu definiowania przepływu pomiędzy parametrami procesu, jego atrybutami oraz parametrami aplikacji, wykorzystywany jest język zapytań do metamodelu procesów – Business Process Query Language (BPQL). Dzięki takiemu podejściu możliwe jest wyrażenie złożonych mapowań w procesie.

Przypisywanie wykonawców

Właściwe przypisanie wykonawców jest istotnym elementem definicji czynności procesu typu Użytkownik i Ręczna. Platforma docuRob®WorkFlow dostarcza zawansowanych mechanizmów przypisywania wykonawców w oparciu o język BPQL. Przy pomocy tego języka można określić wykonawców na podstawie informacji o użytkownikach, strukturze organizacyjnej, posiadanych kompetencjach i pełnionych rolach, historii wykonania procesu, danych statystycznych czy innych specyficznych danych istniejących poza systemem zarządzania procesami pracy. W szczególności platforma docuRob®WorkFlow dostarcza następujące możliwości definicji wyboru:

Statyczny wybór wykonawców – wykonawca czynności może być podany z nazwy (loginu),

Wybór w oparciu o strukturę organizacyjną (struktura hierarchiczna) – wykonawcy mogą być określeni poprzez specyfikacje jednostki organizacyjnej, do której należą, pełnionego stanowiska, czy posiadanych kompetencji. Wybór wykonawcy może być przeprowadzony także na podstawie informacji o relacji podległości pracowników.

Wybór w oparciu o role – innym sposobem jest wykorzystywanie informacji o rolach przydzielonych użytkownikom procesów aby wybrać właściwego wykonawcę.

Wybór w oparciu o funkcjonalne grupy użytkowników (struktura pozioma) – platforma docuRob®WorkFlow umożliwia organizowanie pracowników danej instytucji/firmy w grupy osób posiadających określone kompetencje lub odpowiedzialnych za wykonanie określonej pracy np. wytworzenie produktu, zorganizowanie oferty przetargowej, czy wykonanie specjalistycznej oceny. Dynamiczność oznacza, że grupy te mogą być organizowane w trakcie działalności instytucji/firmy w zależności od konkretnych potrzeb.

Przypisanie uczestników na podstawie historii wykonania procesu pracy – platforma docuRob®WorkFlow pozwala na odwoływanie się w określaniu osób, które mają wykonać zadanie, do historii wykonania procesu. Przykładowo, jeżeli chcemy, aby po decyzji przełożonego informacja o akceptacji trafiła do osoby składającej wniosek, musimy odwołać się do historii wykonania procesu pracy określając na przykład następującą regułę BPQL „to zadanie otrzyma osoba, która wykonała pierwszy etap prac (tzn. złożyła wniosek)”.

Uwzględnianie decyzji ad-hoc w trakcie wykonywania procesu – często zdarzają się sytuacje, dla których wcześniej nie możemy określić, kto ma wykonać daną czynność. W takim wypadku platforma docuRob®WorkFlow umożliwia podejmowanie decyzji Wybierz , czyli określania w trakcie wykonywania (a nie definiowania) procesu, kto zajmie się kolejną czynnością z listy wcześniej wytypowanych osób.

Wykonywanie zadania przez pierwszą osobę z grupy – w przypadku, takiej organizacji pracy, gdzie dana grupa pracowników obsługuje wspólnie grupę zadań (np. kilka okienek i jedna kolejka) możliwość pobrania zadania przez pierwszą osobę, która zgłosi gotowość do jego wykonania jest szczególnie ważna. Mechanizm ten może być też wykorzystany do uniknięcia sytuacji, gdy zadanie zostanie przesłane do osoby, która jest nieobecna lub częściowej kompensacji obciążenia (zadanie bierze pierwsza wolna osoba).

Wykonywanie zadana przez więcej niż jedną osobę – możliwość ta jest szczególnie ważna, gdy chcemy, aby określony etap prac był wykonany przez grupę osób. Przykładowo, gdy rozpatrujemy proces dotyczący odwirusowania komputerów, gdzie każdy z pracowników musi uruchomić ten sam program antywirusowy i przesłać rezultaty do administratora, bez możliwości wykonania odwirusowania przez więcej niż jedną osobę nie jesteśmy w stanie wyrazić tego w definicji procesu. Sposób wykonania odwirusowania po kolei przez każdego z pracowników jako oddzielnego etapu prac też nie jest rozwiązaniem ze względu na trudność w wyrażeniu liczby etapów prac. Liczba ta byłaby zależna od liczby pracowników, która w trakcie zmian kadrowych może się zmieniać.

Tworzenie złożonych warunków wyboru wykonawców – nierzadko wybór wykonawcy jest bardziej złożony od wymienionych powyżej. W takim przypadku system oferuje możliwość definiowania złożonego wyrażenia języka BPQL wybierającego przykładowo „pracownika w danej komórce organizacyjnej, aktualnie obciążonego mniej niż 7 zadaniami, pracującego w naszej organizacji dłużej niż 5 lat”. Funkcje zawarte w wyrażeniu mogą być dowolnie zagłębiane.

Dodawanie nowych funkcji użytkownika - w dowolnym momencie istnieje możliwość zarejestrowania w BPQL nowej funkcji zdefiniowanej na potrzeby konkretnego systemu (np. wyznaczenie aktualnego zapasu wolnych dni danego pracownika).

Zmiana wykonawcy zadania – niekiedy zdarza się iż osoba która została przypisana do wykonania zadania nie jest w stanie go zrealizować (np. została oddelegowana do innych prac lub prozaicznie nie jest obecna w pracy). Powoduje to, iż wspomniana instancja procesu nie może być kontynuowana. Rozwiązaniem takiego problemu jest zmiana wykonawcy czynności.

Wywoływanie aplikacji

W procesie pracy, aby wykonać daną czynność wywoływana jest aplikacja. Platforma docuRob®WorkFlow umożliwia wywołanie aplikacji zarówno w zadaniu użytkownika jak i automatycznej. W pierwszym przypadku aplikacja obsługuje graficzny interfejs użytkownika. W drugim przypadku jest to aplikacja reprezentowana poprzez usługę (program). W ramach wsparcia wywoływania aplikacji system dostarcza następujące możliwości:

Adaptery dla czynności manualnych – w ramach tego interfejsu możliwe jest wołanie różnorodnych adapterów usług dostarczających graficzny interfejs użytkownika wykorzystywanych przez użytkowników procesu. Platforma docuRob® dostarcza standardowo takie usługi jak formularze elektroniczne, repozytorium obiektów i oprogramowanie zarządzające ontologią systemu. Budowanie aplikacji w środowiskach webowych, takich jak na przykład Angular czy React, lub w standardowych językach oprogramowania jest wspomagane przez RestAPI produktów platformy docuRob®.

Adaptery dla czynności automatycznych - w ramach tego interfejsu możliwe jest wołanie różnorodnych adapterów usług takich jak: klasa języka Java lub API wykorzystywanych aplikacji publikowanych jako usługa Rest lub SOAP.

Zarządca czynności automatycznych – zarządca czynności jest odpowiedzialny za optymalne wykonywanie czynności automatycznych. W przypadku dużej liczby takich czynności Zarządca powołuje nowe wątki obsługujące zadania starając się zminimalizować przestoje w przetwarzaniu zadań. Aby nie spowodować zablokowania Zarządcy każda z czynności ma przewidziany maksymalny czas wykonywania, po którym jest ona wywłaszczana.

Równoważenie obciążeń – cały czas podczas działania produktu, Zarządcy procesów rywalizują o przydzielenie i wykonanie zadań automatycznych. Dzięki temu, unika się sytuacji, w której jeden Zarządca jest znacząco bardziej obciążony od innych. Dodatkowo, w przypadku dużej liczby zadań na jednym serwerze możliwe jest automatyczne lub ręczne zwiększanie liczby instancji Zarządców czynności automatycznych na tym samym lub innym, wybranym serwerze. Istnieje także możliwość takiego zdefiniowania Zarządców, aby określone zadania (w ramach procesu, w ramach wszystkich procesów) były przetwarzane na wskazanym serwerze.

Zarządzanie parametrami jakościowymi

Zarządzanie parametrami jakościowymi w obszarze systemów zarządzania procesami pracy ciągle stanowi spore wyzwanie. Platforma docuRob®WorkFlow daje następujące możliwości zarządzania ograniczeniami jakościowymi:

Modelowanie zależności czasowych – często dla danego procesu można określić zależności czasowe. W systemach zarządzania procesami pracy zasadniczo istnieją dwa rodzaje zależności czasowych: czas wykonania lub termin zakończenia.

Powiadamianie o przekroczeniu ograniczeń czasowych – w przypadku kiedy dane ograniczenie czasowe zostanie przekroczone (np. czas realizacji zamówienia wyniesie 5 a nie 4 dni) proces pracy docuRob®WorkFlow powiadomi uprawnionych użytkowników (np. poprzez e-mail) o zaistniałej sytuacji umożliwiając im wykonanie czynności naprawczych (np. zmiana handlowca zajmującego się realizacją zamówienia, pominięcie etapu weryfikacji warunków handlowych, itp.). Osoby powiadamiane są wyznaczane w podobny sposób jak wykonawcy czynności.

Identyfikacja opóźnień należących do ścieżki krytycznej - docuRob®WorkFlow jest w stanie zidentyfikować, czy dane opóźnienie czynności jest krytyczne dla (instancji) procesu. Dzięki temu możliwe jest szybkie wyznaczenie newralgicznych punktów, które mają wpływ na wykonanie całego procesu.

Sygnalizacja zaistniałych opóźnień – system dostarcza bogaty zestaw mechanizmów do sygnalizacji opóźnień. W przypadku zaistnienia opóźnienia na liście zadań oraz w historii wykonania (tekstowej i graficznej) pojawia się specjalny symbol informujący o tym fakcie. Symbol ten reprezentuje także sytuację, gdy opóźnienie ma wpływ na cały proces.

Ostrzeżenie przed możliwością przekroczenia ograniczeń czasowych – system umożliwia także ostrzeganie wybranych użytkowników o możliwości zaistnienia opóźnienia. W trakcie projektowania procesu określa się na jaki czas przed wystąpieniem opóźnienia wysłać takie ostrzeżenie. Powiadamiane osoby są wyznaczane w podobny sposób jak wykonawcy czynności.

Obsługa zdarzeń

Oprócz standardowego przepływu sterowania w ramach procesu docuRob®WorkFlow obsługuje też przepływ sterowania związany ze zdarzeniami. Zdarzenia mogą dotyczyć zarówno otoczenia, jak i samych procesów wykonywanych w produkcie. W ramach tego obszaru system dostarcza następującej funkcjonalności:

Czynność odebrania zdarzenia – w definicji procesu można określić, że dana czynność będzie oczekiwała na zdarzenie. W ramach specyfikacji zdarzenia podaje się typ zdarzenia, oraz inne możliwe atrybuty zdarzenia takie jak typ procesu, czy identyfikator dokumentu, na rzecz którego został uruchomiony dany proces (jego instancja).

Czynność wysłania zdarzenia - w definicji procesu można określić, że dana czynność będzie wysyłała zdarzenie do oczekających na nie czynności odebrania zdarzenia w ramach tego lub innych wykonywanych procesów. Dzięki temu mechanizmowi można wyrażać konieczną synchronizację występującą pomiędzy różnymi instancjami procesów. W ramach specyfikacji zdarzenia podaje się typ zdarzenia, oraz inne możliwe atrybuty zdarzenia takie jak na przykład typ procesu, czy identyfikator dokumentu, na rzecz którego został uruchomiony dany proces (jego instancja).

Obsługa zdarzeń generowanych przez procesy - często istnieje potrzeba, aby wysyłać do innych systemów informację o określonych zdarzeniach związanych z wykonywaniem procesów. Przykładem takiego zdarzenia jest informacja o przerwaniu procesu, która może powodować konieczność zmiany statusu sprawy lub uruchomienia innego procesu. Możliwe jest definiowanie tak zwanych odbiorców zdarzeń. Procesy odbioru zdarzeń są powiadamiane przez docuRob®WorkFlow o wykonywanych zadaniach i mogą reagować we właściwy dla siebie sposób.

Rozbudowany model zdarzeń zgodny z notacją BPMN v. 2.02 jest omówiony w odpowiednich rozdziałach dokumentacji.

Monitorowanie i Administracja

Kolejna ważna grupa usług dostarczana przez docuRob®WorkFlow jest związana z monitorowaniem i administracją wykonywanych procesów. W ramach działań kontrolnych upoważnionego użytkownika możliwe jest:

Sprawdzanie na jakim etapie realizacji jest proces (jego instancja) – dla dowolnego procesu docuRob®WorkFlow udostępnia informację o wykonywanym/wykonanym procesie pracy. Taka informacja dostępna jest w postaci graficznej (graf historii wykonania procesu) jak i tekstowej (opis poszczególnych czynności).

Wyszukiwanie (instancji) procesów i czynności – wyszukiwanie obejmuje bogaty zestaw atrybutów instancji procesu i czynności takich jak nazwa wykonawcy, data rozpoczęcia, status opóźnienia. Przykładowo, przy wykorzystaniu wyszukiwania można szybko sprawdzić, które zadania wpływają na opóźnienie całego procesu.

Kategoryzacja instancji procesów i czynności – w ramach konsoli zarządzania procesami dostępne są standardowe kategoryzacje procesów. Kategoryzacje te dotyczą aktualnego stanu obiektów oraz ich nazw (tzn. instancji procesów i czynności).

Przerywanie instancji procesu/czynności – przerywanie procesu skutkuje przerwaniem wszystkich wykonywanych instancji czynności,

Modyfikacji ograniczeń czasowych – na poziomie procesu i czynności takich jak termin i maksymalny czas realizacji,

Ustalanie priorytetów, dynamiczna zmiana priorytetów – w systemie możliwe jest ustalanie priorytetów w trakcie definicji procesu. Dostępne wartości to: najniższy, niski, normalny, wysoki i najwyższy. W trakcie wykonywania procesu, użytkownik ma prawo zmienić priorytet zadania czynności na wyższy.

Wycofanie czynności - powoduje cofnięcie wykonania procesu do czynności poprzedzającej wybraną czynność. Czynność, która jest wycofywana zostaje ustawiona w stan „przerwana” natomiast czynność poprzedzająca zostaje ponownie otwarta (status „nieodebrana”). Dla wycofywanej czynności możliwe jest też wykonanie czynności kompensującej.

Archiwizacja instancji procesu – archiwizacja instancji procesu polega na wyeksportowaniu do XML informacji o instancji procesu, wszystkich instancji czynności oraz instancji przejść. Zarchiwizowane instancje procesów przechowywane są w archiwum, poza systemem. Archiwizacja dostępna jest dla instancji procesów zakończonych jak również dla procesów w toku.

Obsługa sytuacji wyjątkowych – w trakcie eksploatacji systemu mogą wyniknąć różne sytuacje wyjątkowe, przykładowo błędna definicja WPA może spowodować zatrzymanie instancji procesu z powodu braku uczestnika procesu, do którego należy przekazać pracę.

Struktura definicji procesu pracy

Struktura definicji procesu biznesowego obejmuje, poza omówionymi powyżej elementami notacji graficznej wraz z opcjami wykonawczymi oraz językiem BPQL, opis zewnętrznych zasobów wykorzystywanych w ramach procesu biznesowego oraz wartości parametrów wejściowych przekazywanych mu w trakcie uruchamiania jego instancji.

Podstawowymi elementami każdego procesu są, poza grafem procesu modelowanym zgodnie z notacją BPMN v. 2.02, są takie elementy jak pamięć procesu oraz obiekt informacyjny, na przykład dokument, obsługiwany przez proces. Kontener procesu stanowiący pamięć instancji procesu biznesowego obejmuje wartości wprowadzane do procesu jako parametry inicjacji instancji, oraz zmienne przetwarzane i wykorzystywane przez reguły biznesowe definiowane w języku BPQL. Za pośrednictwem tego języka można również bezpośrednio przetwarzać metadane oraz zawartość obiektu informacyjnego.

Zestaw informacji sterujących wykonaniem procesu zawiera również dane dotyczące ról potencjalnych uczestników procesu oraz ich wzajemnych powiązań i zależności. Takie informacje stanowią standardowe elementy modelu ontologii dziedzinowej procesu, która może zawierać również dowolne pojęcia i powiązania wykorzystywane do modelowania kontekstu dziedziny przetwarzania procesu.

W ramach oprogramowania narzędziowego docuRob®WorkFlow wykorzystujemy moduł Ontology Manager oparty o standard ontologiczny Topic Maps (ISO/IEC 13250:2002). Model danych Topic Maps pozwala na odwzorowanie dowolnie złożonych obszarów dziedzinowych obsługiwanych przez procesy biznesowe. TMSL (Topic Maps Scripting Language) jest wykorzystywany do tworzenia i przetwarzania danych modelu ontologii dziedzinowej. Język skryptowy jest wykorzystywany do ustawiania odpowiednich wartości metadanych obiektu informacyjnego lub, jak w przypadku omawianych poniżej przykładów, do przekazywania odpowiednich danych bezpośrednio do zapytań języka BPQL.

Przykład

Ważnym etapem projektowania systemów informatycznych realizowanych zgodnie z architekturę procesową jest modelowanie procesów pracy ze względu na ich kluczowe znaczenie dla koordynacji i automatyzacji przepływu zadań pomiędzy zespołami funkcjonalnymi organizacji oraz integracji istniejących zasobów danych i usług informatycznych.

Prezentowany przykład modelowania procesów pracy tworzonych w oparciu o narzędzia platformy docuRob®WorkFlow i notację graficzną BPMN 2.02 jest kluczowym elementem cyklu projektowania i wdrażania systemów informatycznych stanowiąc platformę porozumienia i uzgodnień pomiędzy przyszłymi użytkownikami systemu a projektantami procesów.

Omawiany przykład prezentuje model obsługi procesu zamówień w przedsiębiorstwie produkującym roboty przemysłowe. Rysunek 1 i Rysunek 2 prezentują odpowiednio model procesu Zamówienia i model jego podprocesu Analiza kosztu realizacji . Dla lepszej ilustracji proponowanych rozwiązań procesowych przedstawiamy również przebieg wykonania modelowanych procesów prezentowany jako graf historii wykonania instancji procesów.

Przyjęta konwencja reprezentacji ról wykonawców zadań procesów przez oznaczenie ich kolorami pozwala nam budować graf procesu zgodnie z zasadą od lewej do prawej/ z góry w dół zamiast stosowania notacji opartej o tory (ang. lanes). Efektem jest tworzenie znacznie bardziej czytelnych modeli procesów. Role wykonawców zadań występujących w ramach modelu procesu są opisywane w legendzie umieszczonej w lewym dolnym rogu grafu.

Modele procesów zostały opracowane przy pomocy narzędzia projektowanie procesów platformy docuRob®WorkFow zgodne z notacją graficzną BPMN 2.02. Wykonanie instancji procesu reprezentujących alternatywne ścieżki jego przebiegów prezentują Rysunek 4 do Rysunek 11 jako grafy historii wykonania generowane przez usługi monitorowania procesów docuRob®WorkFlow.

Proces biznesowy Zamówienie (Rysunek 1) obsługuje trzy rodzaje zamówień dotyczących: zakupu kompletnego produktu, zakupu części zamiennych lub zakupu usług serwisowych. W ramach każdej z powyższych opcji proces zarządza różnymi ścieżkami przebiegu odpowiadającymi różnym sytuacjom biznesowym. Przyjęto wysoki poziom automatyzacji procedur wspomagany integracją różnych modułów zarządzania produkcją (ERP) oraz dzięki zastosowaniu inteligentnych usług realizowanych przez czynności automatyczne wywołujących zewnętrzne usługi AI (czynność Weryfikacja danych zamawiającego) i model reguł biznesowych BPQL (czynność Analiza wymagań zamówienia).

Wybór procedury obsługi otrzymanego typu zamówienia jest reprezentowany w modelu jako zdarzenie obsługiwane przez bramkę sterowaną zdarzeniami wybierającą ścieżkę procesu odpowiednio dla zdarzenia Części, Produkt lub Serwis. W ramach procesu zaprojektowano wspólne procedury obsługiwane odpowiednio przez podproces sterowany zdarzeniem (podproces Wystawienie faktury) oraz czynność wysłania komunikatu do klienta składającego zamówienie (czynność do Klienta: odmowa realizacji).

Podproces Wystawienie faktury jest wykonywany dla każdej z opcji obsługiwanego zamówienia. Podproces kończy bieg procesu końcowym zdarzeniem rzucającym „Zakończenie”. Wykonanie podprocesu jest inicjowane pośrednim zdarzeniem rzucającym „Sygnał” znajdującym się na ścieżkach procesu odpowiadającym wszystkim trzem opcjom zamówienia.

Czynność do Klienta: odmowa realizacji może być wykonywana dla opcji zamówienia Część lub Serwis poprzedzając zamknięcie procesu końcowym zdarzeniem rzucającym „Błąd” – Nie potwierdzono zamówienia”. Czynność jest inicjowana poprzez pośrednie przerywające zdarzenie krawędziowe „Stoper” oczekujące na wykonanie przez Klienta czynności Potwierdzenie zamówienia lub gdy system ERP ustali (czynność „Sprawdzenie dostępności części”), że lista zamówionych części nie może zostać skompletowana.

W przypadku opcji zamówienia „Produkt” przyjęto w modelu procesu, że zamówienie produktu będzie mogło być odrzucone albo w wyniku negatywnego zakończenia (zdarzenie krawędziowe „Błąd”) podprocesu „Analiza kosztu realizacji” ze względu na błąd w specyfikacji zamówienia (końcowe zdarzenie rzucające „Błąd”) albo w przypadku niepowodzenia negocjacji umowy (zadanie „Negocjacje umowy wykonania produktu”) i przerwania procesu obsługi zamówienia (końcowe zdarzenie rzucające „Przerwanie”).

Model podprocesu „Analiza kosztu realizacji” (Rysunek 2) w którym po ustaleniu typu zamawianego produktu następuje zadanie „Ocena wymagań technicznych” wykonywane sekwencyjnie dla każdego z podzespołów Produktu przez odpowiedniego specjalistę. Podproces kończy się po wykonaniu zadania „Zatwierdzenie wyceny” domniemanym przepływem do końcowego zdarzenia „Koniec” sygnalizującego pozytywne zakończenie analizy. W przypadku Odrzucenia wyniku analizy sygnalizowany jest błąd.

Grafy historii wykonania procesów są umieszczone w dokumencie jako zrzuty ekranów. Lewą stronę ekranu zawierającą Legendę kolorów statusów czynności przedstawia Rysunek 3.

Rysunek 4 do Rysunek 6 przedstawiają dwa warianty wykonania procesu Zamówienie dla opcji zmówienia produktu przy czym Rysunek 5 zawiera graf wykonania podprocesu (czynność 53), którego przebieg był taki sam dla obu wariantów.

Rysunek 7 do Rysunek 8 przedstawiają dwa warianty wykonania procesu Zamówienie dla opcji zakupu części a Rysunek 9 do Rysunek 11 trzy warianty przebiegu procesu Zamówienie dla opcji zakupu usług serwisowych.

Rysunek 1. Model procesu - Zamówienie

Rysunek 2. Model podprocesu – Analiza kosztu realizacji

Rysunek 3. Legenda kolorów statusów czynności grafu historii wykonania procesu

Rysunek 4. Zamówienie – zakup produktu_1

Ostatnią czynnością ścieżki procesu jest końcowe zdarzenie „Zakończenie” powodujące zakończenie instancji poprzez przerwanie obsługi wszystkich czynności niezależnie od ich bieżącego stanu. W analizowanej instancji procesu przerwane zostały wszystkie zdarzenia, które oczekiwały na możliwość wykonania po otrzymania znacznika (ang. token) lub spełnienia zdefiniowanego warunku. Przerywane krawędzie i szare wypełnienie symboli czynności oznacza, że nie otrzymały jeszcze znacznika umożliwiającego ich wykonanie.

Rysunek 5. Analiza kosztu realizacji – zakup produktu_1A

Instancja procesu zakończyła się prawidłowo po wykonaniu trzech kolejnych instancji zadania 4 i pozytywnego zakończenia zadania 6. Ponieważ zamówienie nie zostało odrzucone, proces wybrał przejście wychodzące z czynności 6 do czynności Koniec zamykającej ścieżkę i całą instancję procesu.

Rysunek 6. Zamówienie – zakup produktu_2

Ścieżka procesu Zamówienia (opcja Produkt) reprezentująca przypadek oczekiwanego wykonania (ang. happy path) bez konieczności obsługi nieoczekiwanych przypadków (ang. exception) zakończyła się wystawieniem faktury i wykonaniem końcowej czynności „Przerwanie”.

Rysunek 7. Zamówienie – zakup części zamiennych_1

Po wykonaniu czynności 10 (usługa API_ERP) okazało się, że lista zamówionych części nie może zostać skompletowana. Odpowiednia informacja została przekazana do Klienta (czynność 19) i instancja procesu została zakończona końcowym zdarzeniem „Błąd”

Rysunek 8. Zamówienie – zakup części zamiennych_2

Instancja procesu Zamówienie zakończyła się oczekiwaną ścieżką po Dostawie zamówienia (zadanie 34) i wystawieniu faktury. Ze względu na utrzymanie czytelności modelu procesy wykorzystano pośrednie zdarzenia (odpowiednio rzucające i nasłuchujące) typu Łącze.

Rysunek 9. Zamówienie – zakup usług serwisowych_1

Po automatycznym wykonaniu w systemie ERP (czynność 11) Oceny czasu i kosztów usługi serwisowej i wykonaniu zadania Opracowanie harmonogramu projektu (zadanie 44) przez Sprzedawcę następuje oczekiwanie na wykonanie przez klienta Potwierdzenie zamówienia (zadanie 49). Zdarzenie „Stoper” zostało ustawione na akceptowalny czas oczekiwania na Potwierdzenie zamówienia. Po upłynięciu modelowanego okresu czasu zdarzenie „Stoper” przekazuje znacznik przejściem wyjątku do czynności 19. Po przesłaniu informacji do Klienta proces zostaje zakończony.

Rysunek 10. Zamówienie - Zamówienie – zakup usług serwisowych_2

Ten wariant wykonania instancji procesu ilustruje sytuację w której realizacja projektu usług serwisowych została rozpoczęta (czynność 21) i znacznik został przekazany do zdarzenia typu Warunek. Po spełnieniu warunku zakończenia projektu ścieżka procesu będzie kontynuowana. Zdarzenie zostało oznaczone jako czynność warunkująca termin zakończenia instancji procesu.

Rysunek 11. Zamówienie – zakup usług serwisowych_3

Oczekiwana ścieżka procesu została wykonana a zdarzenie „Przerwij” zakończyło przetwarzanie instancji procesu po wystawieniu faktury.